In related art, the concept of Internet of Things is first proposed at an international mobile computing and network conference held 1999 in the United States. In short, an Internet of Things is a network connecting things. There are two meanings. First, an information provider and an information user are extended from humans gradually to physical entities. Objects communicate and exchange information with each other through the Internet of Things. Secondly, interconnection among physical entities is implemented through various wireless or wired, long-distance or short-distance communication networks, communication and transmission thereof requiring no or limited manual intervention.
Machine to Machine (M2M) communication or Man to Machine (M2M) communication mainly refers to information delivery through a network to implement Machine to Machine or Man to Machine data exchange, i.e. machine interconnection implemented through a communication network.
Compared with Human to Human (H2H) communication, a market for M2M communication is larger. A number of M2M communication terminals is by far greater than that of H2H communication terminals. By inter-ting communication, smart information delivery among a vast amount of machines in the human world may be implemented. Machine to machine communication brings new opportunities and challenges to the entire communication industry and the entire world.
Due to particularity of a mobile communication network, at a terminal side, manual wiring is not required, mobility support may be provided, which facilitate cost saving, and may meet a communication demand in a hazardous environment, such that an M2M service borne on a mobile communication network obtains broad attention in the industry.
With mobile communication technology as a core work, 3rd Generation Partnership Project (3GPP)/3GPP2 focuses on network optimization for Internet of Things traffic to be implemented and provided in a 3rd Generation (3G), Long Term Evolution (LTE), also known as Code Division Multiple Access (CDMA) network. The study relates to fields such as a traffic demand, optimization of a core network and a wireless network, security, etc. M2M within 3GPP is known as MTC. MTC relates to one or more forms of data communication of entities requiring no human interference. MTC service optimization differs from H2H service optimization. MTC differs from communication traffic of a mobile network at present, with features distinguished from those of H2H traffic, namely, a large number of terminals, low mobility, delay insensitivity, a low transmission frequency, etc. In addition, MTC traffic is characterized by Mobile Originate Only, that is, traffic is initiated by an MTC device most of the time.
At present, in MTC communication architecture provided in 3GPP, an MTC server and a Radio Access Network (RAN) may exchange information through an interface MTCsp. An MTC server and an MTC Application may exchange information through an API interface. A wireless access network and an MTC device may interact through an interface MTCu. An interface MTCu may provide a way for an MTC device to access a 3GPP network to deliver user-plane and control-plane traffic. Refer to MTCu/MTCsp/API in 3GPP TR 23.888 v1.6.1, section 6.38.2 for the MTC communication architecture.
As there may be an excessively large number of MTC devices, plus a large number of MTC devices may have to be deployed in a specific area, in a traffic burst, at some point a large number of devices may request to access a wireless network simultaneously, which will lead to simultaneous transmission of a lot of wireless data and signaling, causing access network congestion. Once congestion occurs, intolerable delay, packet loss, or even service unavailability may result. This only will negatively impact the MTC traffic, but also will impact quality of communication of a conventional user. Therefore, for a current network, there is a pressing need for strengthening access network congestion control. A mechanism for ensuring network availability, and means helping a network reach a demand of an MTC device to network performance, have to be found.
To avoid random access congestion caused by simultaneous access by a large number of MTC devices, an access time of an MTC device may be controlled via an application layer. For example, in smart meter reading traffic, simultaneous traffic report by a large number of smart water/electricity meters may be avoided by setting different reporting times in an application layer. However, in future M2M application, there may be a large number of industry applications, which may not be fully operator-controlled, or may not understand the nature of a cellular network, Therefore, such an application will not consider setting application-layer access time control from a perspective of network utilization. In a scene such as earthquake prediction, a large number of sensors have to report alert information within a very short period of time, and a network has to be able to simultaneously process a large number of information reports. Therefore, a method for MTC device access time control for a wireless side also has to be found. Such a solution is transparent to an application layer. A network may handle simultaneous access by a large number of MTC devices with ease, even if no corresponding access time control is set at an application layer.
After the 3GPP TSG RAN2#73 conference, it is decided to avoid MTC overload in a RAN using Extended Access Barring (EAB) in Selective Availability (SA) as baseline. The EAB may include an access control class. A wireless network will broadcast a new an EAB parameter while broadcasting an existing ACB parameter. A terminal configured with EAB will monitor EAB information in system broadcast.
As an improved solution, EAB may allow a network to selectively control an access request from “a device configured with EAB” (with higher tolerance to access barring than other UEs) to prevent access network and core network overload. Thus, no new Access Class is required. In case of congestion, a network may reject an access request from “a device configured with EAB” while allowing access by other UEs. When determining that EAB is right, a network will broadcast necessary information through a BCCH to provide a UE with EAB control. When multiple core networks share one access network, EAB information may be embodied by a Public Land Mobile Network (PLMN).
In the 3GPP TSG RAN2#77 conference, companies reach an agreement on how to broadcast an EAB parameter, i.e., in both a Universal Mobile Telecommunications System (UMTS) and an LTE system, EAB information may be contained in an additional System Information Block (SIB).
EAB in UMTS may be execute as follows. Before an MTC device initiates an access request, first a parameter p (0<p<1) may be broadcast by an access NE. After receiving the p, a device under the access NE will locally generate another parameter q (0<q<1). When q<p, the device may initiate a subsequent access process; otherwise the device will not attempt access. As proposed at present, an access NE may determine the p based on a number of connected users. That is, the more connected users there are, the smaller the p will be set, so as to reduce a number of users who will attempt access to avoid congestion.
However, from the perspective of an MTC device, such parameter setting, considering only the number of connected users, is unreasonable, as with such a mechanism, no difference among MTC devices is taken into account. For example, An MTC device may get no access in a long time, or there may be a lot of to-be sent data in a local buffer thereof, such that there is a long queue accumulated in a memory thereof. When the MTC device determines whether to perform access only by generating the parameter q and comparing the q with the parameter p, access probability thereof will not increase with the queue length in the buffer of the device. In addition, introduction of an EAB mechanism will greatly increase an access time, and thus a device may have no network access in a very long time. In this case when to-be-sent data in the device keeps increasing, buffer overflow may occur, thus leading to packet loss (due to MTC device particularity, to reduce a volume and power consumption, generally storage capacity of an MTC device will not be too large, and thus buffer capacity is limited).